The present invention relates generally to a computer system, program, and method for use by a software developer in revising one or more components in multi-component software builds where the software developer incorporates the components in successive builds. More specifically the present invention relates to gauging one or more effects of revising the component(s) and notifying the developer of the effect(s).
In any programming or software development environment, the software being developed may incorporate a large number of modules or components. Such a software development environment typically includes a range of resources for developing a software product, including tools for building and packaging the product. The software product may be more broadly divided between client and server portions. Such component-based products encourage sharing and reuse of code, which tends to promote efficiency in software development. At the same time, the components within and across each of the client and the server typically have multiple interrelationships and characteristics that affect the performance and other parameters of the software. As the developer creates new components and modifies existing components these characteristics and interrelationships change, sometimes in unexpected manners. For example, components that are not necessary in a build might nonetheless be installed. This may be mitigated through careful planning and a well-defined architecture, but even then component changes may have consequences not predicted by the planning or architecture.
Such component changes may be understood to increase a weight of the component, where the weight is a measure of resources that are requested in order for the component to operate as planned. For example, a software product being developed may be made up of both client and server portions. A developer working on the client side may make a single change to use a method in a component that had not previously been part of the product. As a result, that component is now added as a new dependency. A possible outcome is that, in order for the client to have full functionality, a substantial part of the server portion may need to be installed on the client, increasing the client install size by an amount that outweighs the value of having such method in the new component. Here, the weight of the component may be measured in terms of the extent of its dependencies.
As another example, a Linux user may want to remove a driver, such as a wireless driver, that the user expects not to use for the application at hand. The package manager may indicate that, in order to remove the driver, the entire Linux kernel must also be removed. This effectively makes the wireless driver a requirement even if it will not be used.
Another possible situation is one where a change is made to a component to use a particular open source component. Typically, a requirement of open source components is that any consumers must also be willing to provide source code. Thus, in this situation, a product originally intended to be closed source may now have requirements relating to open source code, which may be incompatible with the plans for use of the software into which the component is incorporated. Here the weight of the component may be measured in terms of the license types required for its planned operation. For these and other examples, it is preferable to provide an early analysis and notification of the potential effects of component change.